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Please aqd the following new claims: 






61. (New) The\method of claim 1 comprising routing the SS7 message to its 
intended destination. 

62. (New) The presence registration and routing node of claim 22 wherein the 
communication module is adapted to route the SS7 message to its intended 
destination. \ 

63. (New) The method oXclaim 1 wherein the telephony related action comprises 
activation of the end user's mobile telephone and wherein the presence 
information indicates thart the end user is currently reachable to receive 
messaging protocol communications via the end user's mobile telephone. 

64. (New) The method of claim \ wherein the telephony related action comprises 
entering a predetermined code via the end user's wireline telephone and 
wherein the presence information indicates that the end user is currently 
reachable via the end user's wireline telephone. 






REMARKS 
Status Summary 

In this Amendment, no claims are cancelled, and claims 61-64 are added. 
Therefore, upon entry of this Amendment, claims 1-64 will be pending. 

Examiner Interview 

Applicants greatly appreciate the Examiner Interview granted them on January 
30) 2003. The amendments above and the remarks below are consistent with the 
discussion in the Examiner Interview. 

Information Disclosure Statement 

In the Official Action, the Information Disclosure Statement filed on December 

4, 2000 was objected to as failing to provide a legible copy of each U.S. and Foreign 

parent or publication. Our records indicate that the Information Disclosure Statement 

filep on December 4, 2000 included copies of each patent or publication cited in the 
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Information Disclosure Statement. In addition, we received a stamped return-receipt 
from the mail room at the United States Patent and Trademark Office indicating that 
copies of the seven references cited in the Information Disclosure Statement were 
received by the United States Patent and Trademark Office. A copy of the 
Information Disclosure Statement, the stamped return-receipt postcard, and the cited 
references are attached hereto. Consideration of the references cited in the 
Information Disclosure Statement is respectfully requested. 

Claim Rejections 35 U.S.C. § 103 
Claims 1-4, 6-22, 24-28, 30-34, and 39-41 were rejected under 35 U.S.C. § 
103(a) as being unpatentable over U.S. Patent No. 6,453,034 to Donovan et al. 
(hereinafter, " Donovan ") in view of U.S. Patent No. 6,252,952 to Kunq et al. 
(hereinafter, " Kunq "). This rejection is respectfully traversed. 

The Present Invention 
Independent claims and 1 and 22 have been amended to recite methods and 
systems for automatically generating presence registration messages based on SS7 
mejssages. For example, claim 1 recites that an SS7 message is received in 
response to a telephony related action performed by an end user. Based on the SS7 
message, it is determined whether presence registration processing is required for 
the; end user. In response to determining the presence registration processing is 
required for the end user, a presence registration message is automatically 
generated . The presence registration message includes presence information 
indicating to other end users a communications medium for contacting the end user 
using a messaging protocol and indicating that the end user is currently available to 

receive messaging protocol communications via the communications medium. 

i 

One example of this type of automatic presence registration is illustrated in 

Figure 8 of the present application. In Figure 8, when an end user activates his or 

her mobile telephone, an SS7 message is generated. Based on the SS7 message, 

the presence registration and routing node of the present invention automatically 
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generates a presence registration message indicating that the end user is current 
available to receive messaging protocol communications via his or her mobile 
telephone. In Figure 9, a similar registration action is performed based on SS7 
messages relating to wireline telephone calls. Automatically generating presence 
registration information indicating the appropriate communications medium for 
contacting a user and that the user is currently available to receive messaging 
protocol communications via the communications medium facilitates the distribution 
of messaging protocol communications. For example, a user is no longer required to 
manually register his or her presence registration information in a presence 
database. Similar amendments have been made to independent claims 1 1 and 35 to 
clarify the meaning of presence registration. 

The Cited References 
As explained in the Examiner Interview, Donovan teaches using SIP 
messages only to establish VPN calls over an IP network. Enterprise gateway 55 
illustrated in Figure 1 of Donovan merely converts SS7 call setup messages to SIP 
messages and vice versa. For example, Donovan states: 

PBX 51 sends a normal setup message with the dialed digits 7774321 
to EG 55. EG 55 performs a protocol translation and formulates a SIP 
INVITE message of the form: 

INVITE:7774321 @xyzus.com 

From:5551 234@xyzmalasia.com 

To:777432 1@xyzs.com (See column 3, lines 38-45 of 

Donovan) 

Based on this passage, Donovan teaches the conventional use of the SS7 and SIP 
protocols for call setup and teaches nothing about registering presence information 
specifying a communications medium for contacting an end user and that the user is 
currently available via the communications medium. Thus, it is respectfully submitted 
that Donovan fails to teach or even remotely suggest the claimed invention. 

Kung likewise fails to teach or suggest automatically generating presence 
registration messages or routing such messages, where the messages include 
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contact information indicating a communications medium for contacting an end user 
via a messaging protocol and that the end user is currently available to receive 
messaging protocol messages via the communications medium. Kung was 
discussed extensively in the Examiner Interview. In particular, the Patent Examiner 
contended that Kung's teaching of the functions of call manager 218 beginning at 
column 10, line 54 rendered the claimed invention obvious. The referenced portion of 
Kuhg states: 

The call manager 218 may incorporate one or more databases. For 
example, the call manager 218 may include database information 
such as (1) a resources database that provides an identification of 
what resources are connected to broadband network one and their 
current state... (See column 10, lines 54-59 of Kung) 

Applicants have specifically amended the claims to recite that the present 
invention automatically generates presence registration information that indicates a 
cuitent communications medium for contacting an end user using a messaging 
protocol and that the end user is currently available to receive messaging protocol 
communications via the messaging protocol . The resources database in the call 
manager of Kung merely stores information about other signaling nodes connected to 
broadband network 1. Examples of signaling nodes disclosed in Kung are signaling 
gateway 234, accounting gateway 240, element management gateway 238, voice 
gateway 232, and media gateway 230. (See column 10, lines 36-39 of Kung). These 
are the "resources" with which call manager 218 may interact and store connection 
and state information. There is absolutely no teaching or suggestion in Kung that call 
manager 218 routes or automatically generates presence registration messages 
indicating the communication medium over which an end user can be contacted and 
whether the end user is currently available to receive messaging protocol 
communications via that communication medium. 

The remaining discussion in the Examiner Interview focused on Kung's 
disclosure of closed user groups. As noted by the Examiner in the Examiner 
Interview, Kung teaches that membership in the closed user group may be 
dynamically defined. However, there is no mechanism taught in Kung for 
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automatically generating or routing messages including presence information 
indicating a communication medium for contacting an end user via a messaging 
protocol and whether the end user is currently available via the communications 
medium to receive messaging protocol messages or for distributing such presence 
information between the members of the closed user group. In contrast, Kunq 
teaches as follows: 

In operation, and referring to Figure 7, a first member (referred to 
herein as "member A") of a CUG may call a second member (referred 
to herein as "member B") of the same CUG (step 701) member A may 
diai the DN of member B, just as any other telephony user would . 
(Emphasis added) (See column 31 , lines 53-57 of Kung .) 

Thus, rather than using dynamically generated presence information, Kung teaches 
that end users contact other users by knowing their static directory numbers. There 
is absolutely no teaching or suggestion in Kung that one end user will know that 
another end user is available at the directory number. In contrast, registering 
presence information according to the present invention indicates not only the 
communications medium for contacting the end user, but alsa that the end user is 
available for receiving messaging protocol communications via the communications 
medium. The fact that Kunq teaches that membership in a closed user group can be 
defined or dynamically changed is irrelevant to the current communications medium 
for sending messaging protocol communications to the user and whether the user is 
available via the communications medium. Thus, for these reasons, it is respectfully 
requested that the rejection of the claims as unpatentable over Donovan in view of 
Kufig be withdrawn. 

Return of Examiner's Copy of Kung 
In addition, Applicants inadvertently obtained a copy of Kung in the Examiner 
Interview that appears to be the Examiner's copy because it contains pencil markings 
corresponding to the portions of Kung cited by the Examiner. That copy is being 
returned with this response. Applicants apologize for any inconvenience this may 
have caused. 
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Rejection Based on Kung. Donovan, and Miller 

Claims 5, 23, and 35-38 were rejected as unpatentable over Donovan in view 
of Kung and further in view of U.S. Patent No. 6,324,183 to Miller et al. (hereinafter, 
" Miller "). This rejection is respectfully traversed. 

As a preliminary matter, Miller is not a proper reference under 35 U.S.C. § 
103(a) because it was commonly owned with the present application at the time the 
invention was made. Thus, Miller does not qualify as a prior art reference under 35 
U.S.C. §103. 

Moreover, even assuming for the sake of argument that Miller is a proper 
reference under 35 U.S.C. § 103, as stated above, the claims of the present 
application recite methods and routing nodes for automatically generating or routing 
messages that include presence information indicating a communications medium 
contacting an end user and whether the end user is currently available to receive 
messaging protocol messages using the communications medium. As indicated 
above, neither Donovan nor Kung teaches the invention as claimed. Miller likewise 
lacks such disclosure. Miller is directed to methods and systems for transmitting and 
receiving SS7 messages over an IP network using signal transfer points. There is no 
disclosure in Miller of transmitting or receiving presence information. Thus, for all the 
reasons stated above, the rejection of the claims as unpatentable over Donovan in 
view of Kung and further in view of Miller should be withdrawn. 

Allowable Claims 

Claim 29 was only objected to. Claim 29 is rewritten in independent form to 
include the limitations of the base claim and any intervening claims. Accordingly, it is 
respectfully requested that claim 29 be allowed. 

Claims 42-60 are allowed. 

Amendments to the Specification 

Clarifying amendments are made to the specification to improve its form. The 

clarifying amendments do not add any new matter. 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 
Pursuant to 37 C.F.R. § 1.121, attached hereto is a marked-up version of the 
changes made to the specification and claims by the current amendment. The 
attached page is captioned "Version with markings to show changes made." 



In light of the amendments and remarks above, it is respectfully submitted that 
the claims are now in condition for allowance. If any small matter should remain 
outstanding after the Patent Examiner has had an opportunity to review the above 
Remarks, the Patent Examiner is respectfully requested to telephone the 
undersigned patent attorney in order to resolve these matters and avoid the issuance 
of another Official Action . 

Although no fee is believed to be due, the Commissioner is hereby authorized 
to charge any fees associated with the filing of this correspondence to Deposit 
Account No. 50-0426. 



CONCLUSION 



Respectfully submitted, 



Suite 1400 University Tower 
31Ci0 Tower Boulevard 



Date: ~2.-f.Q-Q3 




Telephone: (919)493-8000 
Facsimile: (919)419-0383 



Dutjham, North Carolina 27707 



Customer No. Bar Code Label: 



' Hill 



25297 



PATENT TRADEMARK OFFICE 



132|2/40/2 GAH/sed 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 



IN THE SPECIFICATION: 

The paragraph beginning at page 3, line 5, has been amended as follows: 

-In the peer-to-peer approach, a central server maintains a database of online 

subscribers and their associated Internet Protocol addresses. After a subscriber logs 

in, such a server sends the subscriber the IP addresses of everyone on [their] the 

subscriber's contact list who is also currently logged on.- / 

The paragraph beginning at page 4, line 4, has been amended as follows: 

-An entity has control over publication of its presence information. An entity is 

defined as the unit, [e.g. a] e.g.. the person, on whose behalf presence information is 

being maintained. Each entity has a unique handle. The identity of the presence 

server maintaining presence information for the entity can be determined from the 

handle. A handle is well known name for an entity. An example of a handle is 

pp://www.intercom.att.com/TyrantRana. Finally, a point of presence (PoP) is defined 

as a point of presence for an entity. If an entity is present, it is connected to one 

PoP. Each PoP has an address, e.g., an IP address and a port number, at which 

presence messages may be delivered.- / 

The paragraph beginning at page 5, line 19, has been amended as follows: 

-There are currently models, including the models described above, that 

provide for instant messaging (IM) and presence services within the scope of an 

Internet Protocol / data network environment. It will be appreciated from the 

discussion above that one of the key elements of IM operation involves the ability for 

on$ subscriber to "know" when another subscriber is logged in or is "available." From 

the discussion above, it will also be appreciated that the ability to track the login 

status, otherwise known as "presence," of Internet users is fairly well developed and 

widjely practiced. However, as communication networking technology has continued 

to evolve at a rapid pace, so have the means by which end users or subscribers can 

cortimunicate. More particularly, the explosive growth of hand-held, wireless 

communication terminals, such as cell phones, wireless [WEB] Web phones, and 

personal digital assistants has led to a demand for inter-networking or inter-medium 
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communication solutions. In other words, it is rapidly becoming useful for a 
subscriber to have [their] his or her wireless phone status or "presence" known to 
other subscribers, where these other subscribers may be using a variety of 
communication mediums, such as wireless phone service, wired phone service, short 
message service (SMS), or Internet service.-- 

The paragraph beginning at page 7, line 20, has been amended as follows: 
-According to another aspect, a presence registration and routing node 
includes an advanced database communications module (ADCM) for receiving 
queries for presence information. The ADCM module forwards the queries to a 
presence application, such as a SIP, IMPP, or presence application. The presence 
application formulates a presence-server-compatible message, forwards the 
presence-server-compatible message to a presence database, receives a response 
from the database, [an] and forwards the response to the ADCM module to be sent to 
the requestor over an IP network. The presence database may be internal or 
external to the presence registration and routing node.- 

The paragraph beginning at page 9, line 23, has been amended as follows: 
-Figures [5a and 5b] 5(A) and 5(B) are a flow chart illustrating exemplary 
steps that may be performed by a presence registration and routing node in 
processing an 1AM message according to an embodiment of the present invention;- 
The paragraph beginning at page 10, line 22, has been amended as follows: 
-Figure 13 is a block diagram of a presence registration and routing node 
including an external presence database according to an embodiment of the present 
inv^ntion[.];~ 

The paragraph beginning at page 13, line 16, has been amended as follows: 

-Shown in Figure 3 is a schematic diagram of a presence registration and 

routing node 300 of the present invention. It will be appreciated that presence 

registration and routing node 300 includes a high speed Interprocessor Message 

Transport (IMT) communications bus 310. Communicatively coupled to IMT bus 310 

are a number of distributed processing modules or cards including[;] a pair of 

Maintenance and Administration Subsystem Processors (MASPs) 312, an SS7 
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capable Link Interface Module (LIM) 320, an IP capable Advanced Database 

Communication Module (ADCM) 360, and a Presence Registration Module (PRM) 

340. These modules are physically connected to the IMT bus 310 such that signaling 

and other type messages may be routed internally between all active cards or 

modules. For simplicity of illustration, only a single LIM 320, ADCM 360, and PRM 

340 are included in Figure 3. However, it should be appreciated that the distributed, 

multi-processor architecture of the presence registration and routing node 300 

facilitates the deployment of multiple LIM, ADCM, PRM, and other cards, all of which 

could be simultaneously connected to the IMT bus 310.- 

The paragraph beginning at page 14, line 16, has been amended as follows: 

-Focusing now on LIM card functionality, it will be appreciated that LIM 320 is 

comprised of a number of sub-component processes including, but not limited to[;L 

an SS7 MTP level 1 process 322, an SS7 MTP level 2 process 324, an I/O buffer or 

qu^ue 325, a gateway screening (GWS) process 326, a Presence Registration 

Request (PRR) stop action process 328, an SS7 MTP level 3 layer HMDC process 

330, and an HMDT process 332. MTP level 1 and 2 processes 322 and 324, 

respectively, provide the facilities necessary to send and receive digital data over a 

particular physical media / physical interface, as well as to provide error detection / 

correction and sequenced delivery of all SS7 message packets. I/O queue 325 

provides for temporary buffering of incoming and outgoing signaling message 

packets. GWS process 326 is responsible for examining the incoming signaling 

message and determining which, if any, of the provisioned stop actions are 

applicable. PRR stop action process 328 is responsible for making a copy of[,] and 

subsequently encapsulating!,] an incoming SS7 ISDN User Part (ISUP) IAM signaling 

message packet within an SS7 Signaling Connection Control Part (SCCP) formatted 

packet. It should be appreciated that PRR stop action process 328 could also be 

configured to simply encapsulate the original incoming SS7 ISUP IAM signaling 

message, without making a copy. MTP level 3 HMDC process 330 receives 

signaling messages from the lower processing layers and performs a discrimination 

function, effectively determining whether an incoming SS7 message packet requires 
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internal processing or is simply to be through switched. For instance, in the case of 

an SS7 TCAP message associated with presence registration or an SCCP 

encapsulated ISUP 1AM message, HMDC process 330 would determine that the 

message should be internally routed for further processing. [The] HMDT process 332 

manages or directs the internal routing of SS7 message packets that require 

additional processing prior to final routing. Once again, it should be appreciated that 

a LIM card may contain more functional processes than those described above. The 

above discussion is limited to LIM functionality associated with the basic processing 

of in-bound signaling messages.- 

The paragraph beginning at page 16, line 15, has been amended as follows: 

-In general, a PRM card includes the database and database control 

propesses necessary to achieve the presence registration message generation and 

routing functionality of the present invention. The PRM 340 shown in Figure 3 is 

comprised, in part, of an SCCP subsystem controller known as a Signaling 

Connection Routing Controller (SCRC) process 342, a Presence Registration 

Manager (PRMG) process 344, and a number of Presence Registration Applications 

generally indicated by [the] reference numeral 346. Included among the [Presence 

Registration Applications] presence registration applications is a session initiation 

protocol (SIP) registration application process 348 for generating SIP messages, 

forwarding the SIP messages to a presence server, and processing SIP messages 

received from the presence server. The format for SIP messages is described in 

detail in the above-referenced RFC 2543, which defines the SIP protocol. In 

addition, the portion of a SIP message that carries the media capabilities information 

for an end user device is referred to as the session description protocol portion. The 

session description protocol is described in detail in RFC 2327, "SDP: Session 

Description Protocol," (April 1998), the disclosure of which is incorporated herein by 

reference in its entirety.-- 

The paragraph beginning at page 18, line 1, has been amended as follows: 

-(The] SCRC process 342 is responsible for discrimination of signaling 

messages at the SCCP level, and for distributing the signaling messages to an 
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appropriate higher processing level application or function. In the configuration 

shown in Figure 3, the next highest processing level is represented by [the] PRMG 

process 344. PRMG process 344 is responsible for determining how to process the 

incoming message packet. For instance, if the message packet contains an SCCP 

encapsulated ISUP I AM message, PRMG process 344 is configured to de-capsulate 

the original ISUP 1AM message[ ( ] and subsequently extract the appropriate 

information necessary for further processing from the de-capsulated message. 

However, if the incoming message were a TCAP formatted packet, no de-capsuiaiion 

action would be required. In either case, PRMG process 344 is also charged with 

determining which of the provisioned presence registration applications is required for 

successful processing of a particular incoming signaling message packet. As will be 

appreciated from Figure 3, a number of presence registration applications may be 

simultaneously provisioned on a single PRMG card. These presence registration 

applications may be configured such that each application is capable of generating 

presence registration messages that are formatted in different protocols including, but 

not limited to, SIP, IMPP, and presence protocol.- 

The paragraph beginning at page 19, line 17, has been amended as follows: 

-Referring to Figure [5a] 5(A) , in step ST1, an incoming ISUP IAM message is 

recjeived at [the] inbound LIM module 320. In steps ST2 and ST3, the incoming ISUP 

IAM message is received and processed by the MTP Level 1 and 2 processes 322 

and 324, respectively. With MTP Level 1 and 2 processing complete, the signaling 

message packet is temporarily buffered in the I/O queue 325 before being passed up 

the stack to the MTP Level 3 Gateway Screening (GWS) process 326. As indicated 

in step ST4, GWS process 326 examines the incoming ISUP IAM message and 

determines not only whether the message is to be allowed into the switch for further 

prolcessing, but also which, if any, of the provisioned stop actions are applicable to 

thei incoming message. In this example, GWS process 326 examines the incoming 

ISUP IAM message and determines that the message is permitted to enter the 

switch. Furthermore, upon examination of the Originating Point Code (OPC), 

Destination Point Code (DPC) and Sen/ice Indicator Octet (SIO) fields contained in 
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the MTP routing layer, it is determined that the message requires additional 
processing by the PRR stop action 328 (ST5). In [steps] step ST6 PRR stop action 
process 328 receives the ISUP 1AM message from GWS process 326 and 
determines that the incoming message is an ISUP type MSU. The PRR stop action 
process 328 next checks the DPC of the incoming MSU. More specifically, the PRR 
stop action verifies that the DPC of the incoming MSU is a valid PC. PRR stop action 
328 examines the incoming MSU to determine whether presence registration service 
is required. If the incoming MSU is identified as being an ISUP IAM type message, 
PRR stop action 328 encapsulates a copy of the ISUP IAM message within an SCCP 
formatted MSU, as indicated in step ST6. Such SCCP encapsulation is effectively 
achieved by adding essential SCCP message leading and trailing bit sequences to 
the base bit sequence that comprises the ISUP IAM MSU, as generally illustrated in 
Figure 6. Thus, an SCCP type encapsulated MSU is created which envelops or 
contains an ISUP type MSU. Subsequent to this encapsulation, the incoming 
message no longer appears or is treated as an ISUP IAM message within the 
presence registration and routing node 300, but is instead processed internally as an 
SCCP type SS7 message.- 

The paragraph beginning at page 21, line 8, has been amended as follows: 
-However, in the case where an incoming ISUP MSU satisfies the ST5 
criteria, SCCP encapsulation of the ISUP MSU occurs and the resulting encapsulated 
MSU is directed to HMDC process 330 (ST7), where SCCP type processing is 
performed. In the example shown in Figure 3, HMDC process 330 examines the 
message packet and determines that the DPC and Subsystem Number (SSN) of the 
SCCP packet is the [PC] point code of the presence registration and routing node. 
Consequently, further processing of the SCCP MSU within the routing node is 
assumed to be necessary, and the packet is passed to [the] HMDT process 332. 
[Thp] HMDT process 332 examines the Service Indicator (SI) field of the 
encapsulated MSU, which indicates that the encapsulating packet is of an SCCP 
typ0. As such, HMDT process 332 places the encapsulated SCCP MSU on high 
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speed IMT bus 310 for transport to PRM 340 and subsequent presence registration 
service.-- 

The paragraph beginning at page 21, line 21, has been amended as follows: 
-Referring to Figure [5b] 5(B) , in step ST8, the encapsulated SCCP MSU is 
received and examined by SCRC process 342 that is resident on PRM 340. SCRC 
process 342 examines the message, determines that presence registration service is 
indicated, and forwards the encapsulated MSU to the PRMG process 344, as 
indicated by step ST9. In step ST10, PRMG process 344 extracts the ISUP iAM 
MSU from the SCCP envelope and determines that the ISUP MSU requires the 
generation of a SIP-formatted presence registration message (ST11). The ISUP IAM 
MSU is subsequently directed to SIP application 348 for further processing (ST12). 
SIP application 348 examines the ISUP IAM MSU and, using information contained 
within the MSU, generates a SIP-formatted presence registration message (ST13).- 
The paragraph beginning at page 22, line 7, has been amended as follows: 
-With SIP processing complete, the SIP-formatted presence registration 
message is passed to HMRT process 350. HMRT process 350 determines to which 
ADCM card the SIP registration message packet should be routed for subsequent 
outbound transmission (ST14). In this case, the HMRT process 350 determines that 
theidesired outbound signaling link associated with the routing of the SIP registration 
message is located on ADCM 360, Consequently, the SIP message packet is 
internally routed across the IMT bus 310 to LIM 360, where it is [generally] received 
by [the] I/O queue [process] 362 (ST15). Eventually, the modified message packet is 
passed from [the] I/O queue 362 [on] to the IP Level 2 and Level 1 processes 364 
and 366, respectively (ST16). Once again, IP level 1 and 2 processes 366 and 364, 
respectively, provide the facilities necessary to send and receive digital data over a 
particular physical media / physical interface, as well as to provide error detection / 
correction and sequenced delivery of all IP message packets transmitted into the IP 
netyvork. As indicated in step ST17, the SIP-formatted presence registration 
message is then transmitted into an IP network for ultimate delivery to and use by a 
presence database system. - 
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The paragraph beginning at page 22, line 24, has been amended as follows: 

-It will be appreciated that the registration message generation methodology 

shown in Figure 4 is fundamentally similar to the process indicated in Figures [5a and 

5b] 5(A) and 5(B) . The primary difference involves processing variations that result 

from the handling of SS7 ISUP versus SS7 TCAP type messages. Most notably, 

since a TCAP message is, in fact, also an SCCP message, there is no need to 

directly encapsulate or copy and encapsulate the incoming TCAP message. Instead 

the TCAP message is simply directed from the inbound UM -320 to the associated 

PRM 340 via the high speed IMT Bus 310, in much the same manner as the SCCP 

encapsulated ISUP IAM described in detail above. As such, Figure 7 presents a flow 

chart of the major steps associated with the processing of a TCAP-type presence 

registration request message, which may be used in conjunction with the schematic 

diagram shown in Figure 4 to better understand the TCAP based presence 

registration message generation methodology.- 

The paragraph beginning at page 24, line 16, has been amended as follows: 

-In step ST6, the TCAP MSU is received and examined by SCRC process 

342 that is resident on PRM 340. SCRC process 342 examines the message, 

determines that presence registration service is indicated, and forwards the TCAP 

MSiU to the PRMG process 344. As indicated in step ST7, the content of the TCAP 

message is examined to determine whether the TCAP presence registration request 

requires the generation of a SIP-formatted message. In this example, it is assumed 

that the TCAP registration request message requires a SIP-formatted response and a 

as such, is subsequently directed to SIP application 348 for further processing. SIP 

application 348 examines the TCAP MSU and, using information contained within the 

MSU, generates a SIP-formatted presence registration message (ST8).~ 

The paragraph beginning at page 25, line 3, has been amended as follows: 

-With SIP processing complete, the SIP-formatted presence registration 

message is passed to HMRT process 350. HMRT process 350 determines to which 

ADQM card the SIP registration message packet should be routed for subsequent 

outbound transmission (ST9). In this case, the HMRT process 350 determines that 
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the desired outbound signaling link associated with the routing of the SIP registration 

message is located on ADCM 360. Consequently, the SIP message packet is 

internally routed across the IMT bus 310 to LIM 360, where it is [generally] received 

by [the] I/O queue [process] 362 (ST10). Eventually, the modified message packet is 

passed from [the] I/O queue 362 on to the IP Level 2 and Level 1 processes 364 and 

366, respectively (ST11). As indicated in step ST12, the SIP-formatted presence 

registration message is then transmitted into an IP network for ultimate delivery to 

and use by a presence database system .- 

The paragraph beginning at page 25, line 16, has been amended as follows: 

-Shown in Figures 8, 9 and 10 are simplified network diagrams that illustrate 

example implementations of the embodiments described above. More particularly, 

Figure 8 illustrates an implementation of the presence registration and routing node 

300 of the present invention in a mobile or wireless telecommunications environment, 

generally indicated by the numeral 400. Network 400 includes a mobile subscriber 

402, a base station complex 404, a mobile switching center (MSC) 406, a home 

location register (HLR) 408, and a presence server 410. It will be appreciated that 

the message flows shown in Figure 8 indicate that the presence registration and 

routing node 300 formulates and transmits a presence registration message 416 in 

response to the receipt of a location update message 412 that is sent from the MSC 

406. Those skilled in the art of wireless telecommunications will appreciate that an 

MSC performs a number of functions in a wireless network, including the formulation 

anc( routing of signaling messages. In the example shown in Figure 8, the location 

update signaling message used by the presence registration and routing node 300 to 

trigger the presence registration message 416 is destined for [the] HLR node 408. In 

such a wireless scenario, the presence registration message 416 could be formulated 

andi transmitted by the presence registration and routing node in response to a 

mobile location update message associated with the registration of a wireless 

customer in a particular cell or service area. Once again, those skilled in the art of 

wireless or mobile telecommunications will appreciate that wireless or mobile 

signaling messages are generated and transmitted within a wireless network in 
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response to the powering-up or turning-on of a customer's wireless phone, as well as 

in response to inter-cell movement of a mobile subscriber during the course of a 

mobile call. As such, the presence registration and routing node of the present 

invention facilitates a method of presence registration that is completely transparent 

to the cell or mobile phone user.~ 

The paragraph beginning at page 26, line 19, has been amended as follows: 

-Figure 9 illustrates an implementation of [the] presence registration and 

routing node 300 of the present invention in a wired telecommunications 

environment, generally indicated by [the] reference numeral 420. Network 420 

includes a wireline subscriber 422, an end office (EO) 424, and a presence server 

426. It will be appreciated that the message flows shown in Figure 9 indicate that 

[the] presence registration and routing node 300 formulates and transmits a presence 

registration message 434 in response to the receipt of an ISUP call signaling 

message from [the] EO 424. More particularly, [the] presence registration message 

434 is generated in response to the receipt of an ISUP Initial Address Message (IAM) 

message 428. Those skilled in the art SS7 signaling will appreciate that an ISUP 

IAM message is the first in a sequence of ISUP formatted SS7 call control signaling 

messages that are required to complete a phone call in the Public Switched 

Telephone Network (PSTN). As such, it will be appreciated that in the scenario 

illustrated in Figure 9, [the] presence registration message 434 is formulated in 

response to an attempt by [the] wireline subscriber 422 to place a telephone call. As 

presence registration message generation is triggered by an ISUP IAM message, it 

will be appreciated by those skilled in the art of SS7 telecommunications that 

completion of an attempted telephone call is not required in order for a presence 

registration message to be generated and transmitted to a presence server. Thus, 

any call attempts by [the] wireline subscriber 422 will effectively register the 

subscriber's presence with [the] presence server 426 via [the] presence registration 

and routing node 300 of the present invention. It will also be appreciated from Figure 

9, that [the] triggering ISUP IAM message 428 is subsequently routed [as normal, on] 

to a destination address specified in the message. - 
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The paragraph beginning at page 27, line 20, has been amended as follows: 

-Shown in Figure 10 is a variation of the scenario that was illustrated in Figure 

9 whereby an SS7 signaling message used to trigger the formulation and subsequent 

transmission of a presence registration message is comprised of a TCAP-type 

message instead of an ISUP-type message. Shown in Figure 10 is an 

implementation of [the] presence registration and routing node 300 of the present 

invention in a wired telecommunications environment, generally indicated by [the] 

reference numeral 440. Network 440 includes a wireline subscriber 442, an end 

office (EO) 444, and a presence server 446. In the particular embodiment shown in 

Figure 10, it is assumed that the wireline subscriber 442 indirectly initiates a TCAP 

message 448 by dialing "*88" or a similar code on a telephone keypad. Once again, 

those skilled in the art of SS7 telecommunication networks will appreciate that 

generation of such TCAP messages is accomplished by an End Office (EO) or 

Service Switching Point (SSP) in response to the M *88" keystrokes, as generally 

indicated in Figure 10. As such, by dialing w *88" [the] wireline subscriber 442 is 

effectively manually registering [their] his or her presence with the presence server 

via the generation of the TCAP message 448, which in turn causes the generation of 

a presence registration message 450 by [the] presence registration and routing node 

300 of the present invention.- 

The paragraph beginning at page 28, line 16, has been amended as follows: 

-The embodiments of the present invention described in detail above can be 

easfly extended to include a presence registration and routing node that is capable of 

maintaining a presence database system. One embodiment of such a presence 

registration and routing node is illustrated in Figure 11, and generally indicated by 

[the] reference numeral 500. It will be appreciated that in the particular embodiment 

presently contemplated, presence registration messages are not formulated and 

routed from the node[, but], [instead] Instead presence registration takes place at or 

withJn the node. That is, in the embodiment of the present invention shown in Figure 

11 and [generally discussed] described below, the functionality of a presence server 

is [generally] included within [the] presence registration and routing node 500.- 
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The paragraph beginning at page 29, line 3, has been amended as follows: 
-With particular regard to the embodiment illustrated in Figure 11 and in a 
manner similar to the embodiment described above, it will be appreciated that 
presence registration and routing node 500 includes a high speed Interprocessor 
Message Transport (IMT) communications bus 310. Communicatively coupled to 
IMT bus 310 are a number of distributed processing modules or cards including!;] a 
pair of Maintenance and Administration Subsystem Processors (MASPs) 312, an 
SS7 capable Link Interface Module (LIM) 320, an IP capable Advanced Database 
Communication Module (ADCM) 360, and a Presence Database Module (PDM) 502. 
These modules are physically connected to the IMT bus 310 such that signaling and 
other type messages may be routed internally between all active cards or modules. 
For simplicity of illustration, only a single LIM 320, ADCM 360, and PDM 502 are 
included in Figure 11. However, it should be appreciated that the distributed, multi- 
processor architecture of the presence registration and routing node 500 facilitates 
the deployment of multiple LIM, ADCM, PDM, and other cards, all of which could be 
simultaneously connected to the IMT bus 310.- 

The paragraph beginning at page 29, line 24, has been amended as follows: 
-Once again, it will be appreciated that LIM 320 is comprised of a number of 
sub-component processes including, but not limited to[;] an SS7 MTP level 1 process 
322, an SS7 MTP level 2 process 324, an I/O buffer or queue 325, a gateway 
screening (GWS) process 326, a Presence Server Request (PRR) stop action 
process 328, an SS7 MTP level 3 layer HMDC process 330, and an HMDT process 
332. MTP level 1 and 2 processes 322 and 324, respectively, provide the facilities 
necessary to send and receive digital data over a particular physical media / physical 
interface, as well as to provide error detection / correction and sequenced delivery of 
all SS7 message packets. I/O queue 325 provides for temporary buffering of 
incoming and outgoing signaling message packets. GWS process 326 is responsible 
for examining the incoming signaling message and determining which, if any, of the 
provisioned stop actions are applicable. PRR stop action process 328 is responsible 

for making a copy of, and subsequently encapsulating, an incoming SS7 ISDN User 
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Part (ISUP) 1AM signaling message packet within an SS7 Signaling Connection 

Control Part (SCCP) formatted packet. It should be appreciated that PRR stop action 

process 328 could also be configured to simply encapsulate the original incoming 

SS7 ISUP 1AM signaling message, without making a copy. MTP level 3 HMDC 

process 330 receives signaling messages from the lower processing layers and 

performs a discrimination function, effectively determining whether an incoming SS7 

message packet requires internal processing or is simply to be through switched. For 

instance, in the case of an SS7 TCAP message associated with presence registration 

or an SCCP encapsulated ISUP 1AM message, HMDC process 330 would determine 

that the message should be internally routed for further processing. [The] HMDT 

process 332 manages or directs the internal routing of SS7 message packets that 

require additional processing prior to final routing. Once again, it should be 

appreciated that a LIM card may contain more functional processes than those 

described above. The above discussion is limited to LIM functionality associated with 

the basic processing of in-bound signaling messages.- 

The paragraph beginning at page 31 , line 15, has been amended as follows: 

-The processes explicitly shown on [the] out-bound ADCM 360 include an I/O 

queue 362 and IP level 1 and 2 processes 366 and 364, respectively. I/O queue 362 

facilitates temporary buffering of incoming and outgoing signaling message packets, 

while IP addressing operations are performed by [the] IP level 1 and 2 processes 366 

and 364, respectively.- 

The paragraph beginning at page 32, line 1, has been amended as follows: 

-In general, a PDM card includes the database and database control 

processes necessary to facilitate the presence registration and query handling 

functionality of the contemplated embodiment of the present invention. [The] PDM 

502i shown in Figure 1 1 is comprised, in part, of an SCCP subsystem controller 

known as a Signaling Connection Routing Controller (SCRC) process 504, a 

Presence Database Manager (PDMG) process 510, and a number of Presence 

Database Interface (PDI) Applications generally indicated by the numeral 512. 

Included among [the] PDI Applications 512 are session initiation protocol (SIP) 
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application process 518, IMPP application process 514, and presence protocol 

process 519. [The] SCRC process 504 is responsible for discrimination of signaling 

messages and subsequent distribution of these signaling messages to an 

appropriate higher processing level application or function. In the configuration 

shown in Figure 11, the next highest processing level is represented by [the] PDMG 

process 510. PDMG process 510 is generally responsible for determining which of 

the provisioned protocol-specific PDI Applications 512 is required process the 

incoming message packet. For instance, if the incoming presence registration packet 

contained a TCAP or SCCP-encapsulated IMPP message, PDMG process 510 

would determine that [the] provisioned PDI application 514 was required for 

successful processing. As will be appreciated from Figure 11, a number of PDI 

applications 512 may be simultaneously provisioned on a single PDMG card. These 

protocol-specific PDI applications may be configured such that each application is 

capable of receiving presence registration or query messages that are formatted in 

different protocols including, but not limited to, SIP, IMPP, and the presence protocol. 

Furthermore, these PDI applications 512 are also capable of generating or formatting 

protocol-specific presence service related response messages. Such a presence 

service response message might include, but is not limited to, a message that 

provides presence status information for a specific user in response to a presence 

status query. This particular scenario is specifically illustrated in Figure 11, where the 

presence status query packet assumes the form of an SS7 TCAP-encapsulated 

IMPP query message and the subsequent presence status response is contained 

within a SIP formatted message.- 

The paragraph beginning at page 33, line 9, has been amended as follows: 

-Once again, while any number or variety of PDI applications may be 

provisioned on a single PDM card, only [the] IMPP, SIP, and presence protocol PDI 

applications 514, 518, and 519, respectively, are described herein. SIP PDI 

application 518 [essentially] contains the logic necessary to process incoming SIP 

presence messages and construct outgoing SIP presence response messages. 

Similarly, IMPP PDI application 514 contains the logic necessary to process incoming 
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IMPP formatted presence messages and construct outgoing IMPP formatted 
presence response messages. Presence PDI application 519 contains the logic 
necessary to process incoming presence query messages formatted according to the 
presence protocol and construct outgoing presence response messages formatted 
according to the presence protocol.- 

The paragraph beginning at page 34, line 4, has been amended as follows: 
-With particular regard to the scenario generally illustrated in Figure 11, it is 
assumed that an incoming TCAP-encapsulated IMPP formatted presence query- 
message is received at the inbound LIM module 320 (ST1). Once again, in steps 
ST2 and ST3, the incoming TCAP-encapsulated IMPP formatted presence query 
message is received and processed by the MTP Level 1 and 2 processes 322 and 
324, respectively. With MTP Level 1 and 2 processing complete, the signaling 
message packet is temporarily buffered in the I/O queue 325 before being passed up 
the stack to the MTP Level 3 Gateway Screening (GWS) process 326. As indicated 
in step ST4, GWS process 326 examines the incoming TCAP presence query 
message and determines not only whether the message is to be allowed into the 
switch for further processing, but also which, if any, of the provisioned stop actions 
are applicable to the incoming message. In the scenario shown in Figure 11, GWS 
process 326 examines the incoming TCAP-encapsulated IMPP presence query 
message and determines that the message is permitted to enter the switch. 
Furthermore, upon examination of the Originating Point Code (OPC), Destination 
Point Code (DPC) and Service Indicator Octet (SIO) fields contained in the MTP 
routing layer, it is determined that the message does not require additional 
processing by [the] PRR stop action 328. As such, the TCAP MSU is then routed 
directly to HMDC process 330 where SCCP type processing is performed (ST5). In 
the example shown in Figure 11, HMDC process 330 examines the message packet 
and determines that the DPC and Subsystem Number (SSN) of the TCAP packet is 
the PC and SSN of the internal presence server database system that is located on 
PDM card 502. Consequently, further processing of the TCAP MSU within the 

routing node is assumed to be necessary, and the packet is passed to the HMDT 
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process 332. [The] HMDT process 332 examines the Service Indicator (SI) field of 

the TCAP MSU, which indicates that the packet is of an SCCP type. As such, HMDT 

process 332 places the TCAP MSU on high speed IMT bus 310 for transport to PDM 

502 and subsequent presence database service. ~ 

The paragraph beginning at page 35, line 9, has been amended as follows: 

-In step ST6, the TCAP MSU is received and examined by SCRC process 

504 that is resident on PDM 502. SCRC process 504 examines the message, 

determines that presence database service is indicated, and forwards the TCAP 

MSU to [the] PDMG process 510. As indicated in step ST7, the message packet is 

examined to determine the protocol of the presence related message. In this case, 

the protocol of the presence related message encapsulated within the TCAP packet 

is IMPP. Next A in step ST8 A the variety or type of presence service associated with 

the message is evaluated. Such general presence message types or varieties might 

include, but are not limited to, query and registration type messages.-- 

The paragraph beginning at page 37, line 8, has been amended as follows: 

-With particular regard to the embodiment illustrated in Figure 13 and in a 

manner similar to the embodiment described above, it will be appreciated that 

presence registration and routing node 600 includes a high speed Interprocessor 

Message Transport (IMT) communications bus 310. Communicatively coupled to 

IMT bus 310 are a number of distributed processing modules or cards including: a 

pair of Maintenance and Administration Subsystem Processors (MASPs) 312, an 

SS7 capable Link Interface Module (LIM) 320, an IP capable Advanced Database 

Communication Module (ADCM) 360, and an External Presence Database Module 

(EPDM) 700. As further indicated in Figure 13, EPDM 700 is connected to an 

external Presence Database Server platform 800 via a high-speed Ethernet-type 

connection 802. In this embodiment, external Presence Database Server platform 

800 includes the actual Presence Database entity 516. With exception of [the] EPDM 

carcj 700 and external Presence Database Server 800, all other functional and 

operational aspects of the embodiment shown in Figure 13 are identical to that of the 

embodiment shown in Figure 1 1 and [generally] described above.- 
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The paragraph beginning at page 38, line 1, has been amended as follows: 

-In general, an EPDM card 700 includes the database and database control 

processes necessary to facilitate the presence registration and query handling 

functionality of the contemplated embodiment of the present invention. [The] EPDM 

700 shown in Figure 13 is comprised, in part, of an SCCP subsystem controller 

known as a Signaling Connection Routing Controller (SCRC) process 504, a 

Presence Database Manager (PDMG) process 510, and a number of Presence 

Database Interface (PDI) [Applications] applicatio ns generally indicated by the 

numeral 512. Included among [the] PDI [Applications] applications 512 are a session 

initiation protocol (SIP) application process 518, an IMPP application process 514, 

and a presence protocol process 519. [The] SCRC process 504 is responsible for 

discrimination of signaling messages and subsequent distribution of these signaling 

messages to an appropriate higher processing level application or function. In the 

configuration shown in Figure 13, the next highest processing level is represented by 

[the] PDMG process 510. PDMG process 510 is generally responsible for 

determining which of the provisioned protocol-specific PDI [Applications] applications 

512 is required process the incoming message packet. [The] PDI applications 512 

are capable of generating or formatting protocol-specific presence service related 

response messages. Such a presence service response message might include, but 

is not limited to, a message that provides presence status information for a specific 

user in response to a presence status query .- 

The paragraph beginning at page 39, line 10, has been amended as follows: 

-Shown in Figure 14 is another embodiment of a presence registration and 

routing node of the present invention, generally indicated by [the] reference numeral 

900. With particular regard to the embodiment illustrated in Figure 14 and in a 

manner similar to the embodiment described above, it will be appreciated that 

presence registration and routing node 900 includes a high speed Interprocessor 

Message Transport (IMT) communications bus 310. As in the previously described 

embodiments, communicatively coupled to IMT bus 310 are a number of distributed 

processing modules or cards including!;] a pair of Maintenance and Administration 
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Subsystem Processors (MASPs), an SS7 capable Link Interface Module (LIM) 320, 

and an IP capable Advanced Database Communication Module (ADCM) 360, and a 

Presence Registration Module (PRM) 340. Further included in [the] presence 

registration and routing node 900 is an accounting and billing subsystem which is 

comprised of an accounting subsystem interface module (ASIM), generally indicated 

by [the] reference numeral 91 0[J and an accounting server platform (ASP), generally 

indicated by [the] reference numeral 920. It will be appreciated that the combination 

of ASIM card 910 and ASP accounting server 920 includes the database and control 

processes necessary to achieve the accounting and billing functionality of the present 

invention. From a practical implementation standpoint, ASP 920 could assume the 

form of a Sun Workstation or similar type computing platform. It will be further 

appreciated that an entire message accounting subsystem could also be integrated 

within a presence routing and registration node.- 

The paragraph beginning at page 40, line 7, has been amended as follows: 

-[The] ASIM card 910 shown in Figure 14 includes a Signaling Connection 

Control Part (SCCP) subsystem 912 that is responsible for receiving and preliminary 

processing of incoming SCCP encapsulated accounting message packets. ASIM 

card 910 also includes an SCCP controller known as a Signaling Connection Routing 

Controller (SCRC) process 914 and a high-speed Ethernet Controller (EC) process 

916. Once again, as described above, [the] SCCP subsystem 912 is responsible for 

receiving and preliminary processing of incoming SCCP encapsulated message 

packets, while [the] SCRC process 914 is responsible for discrimination and 

subsequent distribution of messages based on information contained in an SCCP 

packet. In the case of ASIM card 910, messages that satisfy the SCRC 

discrimination criteria are distributed or directed to [the] high-speed Ethernet 

Coritroller process 916. EC process 916 is in turn responsible for controlling the 

process of communicating messages, via an Ethernet connection to and from [the] 

associated ASP server 920. More particularly, ASP server 920 includes a 

corresponding high-speed Ethernet Controller process 922 that serves as the 

communications interface between ASIM card 910 and an on-board accounting 
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server manager (ASM) process 924. ASM process 924 is responsible for the de- 
capsulation or removal of the SCCP envelope that contains the accounting message. 
The de-capsulated accounting message is then passed to an adjacent usage and 
measurements process 926 where usage [and] measurement statistics are created 
and stored in a usage [and] measurements database (UMD) process 930, such as 
that shown in Figure 15.- 

The paragraph beginning at page 41 1 line 6, has been amended as follows: 
-Usage [and] measurements statistics produced by such a process could 
include, but are not limited to, peg counts of messages received from a specific 
network address, a specific service provider, a specific service user, a specific IP 
socket, or a specific signaling link. Furthermore, information specific to the type of 
service requested, calling and called party information, and other information 
associated with a communication that could be useful in generating a bill or invoice 
may also be stored in a UMD. As shown in sample UMD process 930, in one 
simplified embodiment, each communication is identified by a transaction ID, and 
certain predetermined information associated with a communication can be stored in 
the database. It will be appreciated that the information contained in a UMD 
database could be significantly more or less detailed than that indicated in the 
example shown in Figure 15.- 

The paragraph beginning at page 43, line 20, has been amended as follows: 
-Figure 16 illustrates yet another embodiment of a presence registration and 
routing node of the present invention, which extends the integrated accounting and 
billing subsystem concept to the routing node previously presented in Figure 11. This 
new embodiment of a presence server and routing node is generally indicated by 
[the] reference numeral 950. With particular regard to the embodiment illustrated in 
Figure 16 and in a manner similar to those embodiments described above, it will be 
appreciated that presence registration and routing node 950 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. Communicatively 
coupled to IMT bus 310 are a number of distributed processing modules or cards 

including!;] a pair of Maintenance and Administration Subsystem Processors 
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(MASPs), an SS7 capable Link Interface Module (LIM) 320, and an IP capable 
Advanced Database Communication Module (ADCM) 360, and a Presence 
Registration Module (PRM) 340. Further included in the presence registration and 
routing node 950 is an accounting and billing subsystem which is comprised of an 
accounting subsystem interface module (ASIM), generally indicated by [the] 
reference numeral 910, and an accounting server platform (ASP), generally indicated 
by [the] reference numeral 920. Again, it will be appreciated that the combination of 
ASIM card 910 and ASP accounting server 920 includes the database and control 
processes necessary to achieve the accounting and billing functionality of the present 
invention. -- 

The paragraph beginning at page 44, line 16, has been amended as follows: 
-In the particular embodiment shown, LIM card 320 includes a Presence 
Registration Request (PRR) stop action process 952, that is functionally similar to 
[the] PRR process 902 described above. PRR 952 is adapted to generate!,] and 
SCCP = encapsulate[,] an accounting message that is subsequently passed via IMT 
bus 310 to ASIM 910 of the accounting and billing subsystem, where accounting and 
billing subsystem processing occurs in a manner similar to that described above.- 

IN THE CLAIMS: 

The claims have been amended as follows: 

1 . (Amended) A method for updating presence information regarding an end user 
in a presence server database based on information derived from a telephony- 
related action, the method comprising: 

(a) receiving a signaling system seven (SS7) message in response to a 
telephony-related action performed by an end user; 

(b) determining, based on the SS7 message, whether presence registration 
processing is required for the end user: 

f(b)](c)in response to [receiving the SS7 message, formulating an internet 

protocol (IP) message for updating presence information regarding the 

end user managed by a presence server ldetermininq that presence 
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registration processing is required for the end user, automatically 
generating a presence registration message including presence 
information indicating to other end users a communication medium for 
contacting the end user using a messaging protocol and indicating that 
the end user is currently available to receive messaging protocol 
messages via the communications medium : and 
f(c)1(d)transmitting the NP Ipresence registration message to the presence 
server over an IP network. 

6. (Amended) The method of claim 1 wherein [formulating an IP message 
includes formulating lautomaticallv generating a presence registration message 
includes automatically generating a presence protocol message. 

7. (Amended) The method of claim 1 wherein [formulating an IP message 
includes formulating lautomaticallv generating a presence registration message 
includes automatically generating a session initiation protocol (SIP) message. 

8. (Amended) The method of claim 1 wherein [formulating an IP message 
includes formulating lautomaticallv generating a presence registration message 
includes automatically generating an instant messaging and presence protocol 
(IMPP) message. 

1 1 . (Amended) A method for processing a query to a presence server database, 
the method comprising: 

(a) receiving, at presence registration and routing node, an IP message for 
determining presence information for [an entitv la first end user, the 
presence information indicating a communication medium for contacting 
the first end user using a messaging protocol and the fact that the first 
end user is currently available to receive messaging protocol messages 
via the communications medium : 

(b) formulating a query to a presence database for obtaining the presence 
information; 

(c) obtaining the presence information from the presence database; and 
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(d) forwarding the presence information to ten ia second end use r, wherein 
the second end user uses the presence information to determine the 
appropriate communication medium for contacting the first end user 
using the messaging protocol and the availability of the first end user to 
receive messaging protocol communications via the communications 
medium . 

14. (Amended) The method of claim 11 wherein forwarding the presence 
information to fan la second end user includes forwarding a presence protocol 
message to the second end user. 

15. (Amended) The method of claim 14 wherein forwarding a presence protocol 
message includes forwarding a notify message to the second end user. 

22. (Amended) A presence registration and routing node for updating presence 
information regarding an end user in a presence server database, the 
presence registration and routing node comprising: 

(a) a communication module for receiving an SS7 message [from an SS7 
network lrelating to an end user and for determining whether presence 
registration processing is reguired for the SS7 message : and 

(b) a presence server message generator for, if the communication module 
determines that presence registration processing is reguired. for 
receiving a copy of the SS7 message and for automatically generating 
a fpresence-server-compatibte lpresence registration message [for 
updating presence information regarding an end user in a presence 
server database, based on the SS7 message lincluding presence 
information indicating to other end users a communication medium for 
contacting the end user and the fact that the end user is currently 
available to receive messaging protocol messages via the 
communications medium . 

23. (Amended) The presence registration and routing node of claim 22 comprising 
an advanced database communication module for encapsulating the 
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fpresence-server-compatiblel presence registration message in an IP packet 
and transmitting the IP packet to a presence server over an IP network. 

24. (Amended) The presence registration and routing node of claim 22 wherein 
the [presence-server-compatible lpresence registration message is a session 
initiation protocol (SIP) message. 

25. (Amended) The presence registration and routing node of claim 22 wherein 
the [presence-server-compatible lpresence registration message is a presence 
protocol message. 

26. (Amended) The presence registration and routing node of claim 22 wherein 
the [presence-server-compatible lpresence registration message is an instant 
messaging and presence protocol (IMPP) message. 

29. (Amended) [The] A presence registration and routing node [of claim 22] for 
updating presence information regarding an end user in a presence server 
database, the presence registration and routing node comprising: 

(a) a communication module for receiving an SS7 message from an SS7 
network; and 

(b) a presence server message generator for generating a presence- 
server-compatible message for updating presence information 
regarding an end user in a presence server database, based on the 
SS7 message, wherein the SS7 message is a message from a mobile 
switching center (MSG). 

35. (Amended) A presence registration and routing node for providing presence 
information regarding an entity, the presence registration and routing node 
comprising: 

(a) an advanced database communications module for receiving an IP- 
encapsulated presence-server-compatible message for determining 
presence information for [an entitv la first end user, the presence 
information indicating a communication medium for contacting the first 
end user using a messaging protocol and the fact that the first end user 
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is currently available to receive messaging protocol messages via the 
communications medium : and 
(b) a presence server message processor operablv associated with the 
advanced database communications module for forwarding the 
presence-server-compatible message to a presence server for 
determining the presence information , wherein the presence server 
stores the presence information for the first end user and responds to 
the presence-server-compatible message, thereby informing a second 
end user of the appropriate communications medium for contacting the 
first end user using messaging protocol communications and whether 
the first- end user is currently available to receive messaging protocol 
messages via the communications medium. 



The following new claims have been added: 

61. (New) The method of claim 1 comprising routing the SS7 message to its 
intended destination. 

62. (New) The presence registration and routing node of claim 22 wherein the 
communication module is adapted to route the SS7 message to its intended 
destination. 

63. (New) The method of claim 1 wherein the telephony related action comprises 
activation of the end user's mobile telephone and wherein the presence 
information indicates that the end user is currently reachable to receive 
messaging protocol communications via the end user's mobile telephone. 

64. (New) The method of claim 1 wherein the telephony related action comprises 
entering a predetermined code via the end user's wireline telephone and 
wherein the presence information indicates that the end user is currently 
reachable via the end user's wireline telephone. 
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